BEST AVAILABLE COPY 




Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Bescheinigung Certificate Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprGnglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Paten tan mel- 
dung Qberetn. 



The attached documents 
are exact copies of the 
European patent application 
described on the foliowing 
page, as originally filed. 



Les documents fixes a 
cette attestation sont 
conformes a la version 
initialement deposee de 
la demande de brevet 
europeen specifiee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n° 

03104970.3 y 



PRIORITY 
DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH RULE 17.1(a) OR (b) 



Der President des Europaischen Patentamts; 
Im Auftrag 

For the President of the European Patent Office 

Le President de I'Office europeen des brevets 
p.o. 



R C van Dijk 



EuropaSsches European Office europeen 

Patentamt Patent Office des brevets 



Anmeldung Nr: Anmeldetag: 

Application no.: 03104970.3 \S Date of filing: 24.12.03 V 

Demande no: Date de d^pot: 



Anmel der/Appl lean t( s)/Demandeur( s) : 

Koninklijke Philips Electronics N.V. 
Groenewoudseweg 1 
5621 BA Eindhoven 
PAYS-BAS 



Bezelchnung der Erf 1 ndung/T1 tie of the 1nvent1on/T1tre de l'1nvent1on: 
(Falls die Bezelchnung der Erftndung nlcht angegeben 1st, slehe Beschrelbung. 
If no title Is shown please refer to the description. 
S1 aucun tltre n'est 1nd1qu6 se referer a la description.) 

Preserving privacy while using authorization certificates 



In Anspruch genommene Pr1or1at(en) / Pr1or1ty(1es) claimed /PHor1t6(s) 
revendlquee(s) 

Staat/Tag/Aktenze1chen/State/Date/F1le no./Pays/Date/Numero de depot: 



Internationale Patentklasslf 1 katl on/International Patent Classification/ 
Classification Internationale des brevets: 

G06F1/00 

Am Anmeldetag benannte Vertragstaa ten/Contracting states designated at date of 
flllng/Etats contractants designees lors du depot: 

AT BE BG CH CY GZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL 
PT RO SE SI SK TR LI 



03104970.3 

EPA/EP0/0EB Form 1014.2 - 01.2000 7001014 



2 



PHNL03 1 509EPP 

1 

Preserving privacy while using authorization certificates 



24.12.2003 



10 



The invention relates to a method of preserving privacy for a user while 
enabling the user controlled access to data. The invention further relates to a user device for 
preserving privacy for a user while enabling the user controlled access to data. The invention 
further relates to a verifier device for preserving privacy for a user while enabling the user 
controlled access to data. The invention further relates to an issuing device for preserving 
privacy for a user while enabling the user controlled access to data. The invention further 
relates to a signal for preserving privacy for a user while enabling the user controlled access 
to data. 

The invention further relates to a computer program product for preserving 
privacy for a user while enabling the user controlled access to data. 



The SPK3/SDSI (Simple Public Key Infrastructure/Simple Distributed 
Security Infrastructure) certificate framework is described in Ellison, C, "SPKI/SDSI 

15 certificates ", ^.//wnrlrf , st d,co»»/^m P /htm1/ S pki.hunl. Within this framework, 

authorization certificates can be defined by means of which an authorization or right is 
granted to the public key of a person by an authority which signs the certificate. In addition to 
me authorization and the subject, SPKI authorization certificates also include the public key 
of the issuing authority, and may also include a validity specification for die certificate and a 

20 delegation tag. 

Authorization certificates may be carried by the user (e.g., in their user 
devices), or may be available anywhere in the network (to avoid the burden on the user of 
carrying all his certificates) to allow easy access to those certificates to a verifier. In this case, 
all information present in the certificate is in the clear in the network and available for 
25 anyone to see. 

For authorization certificates, their issuing, their possible public wide 
availability as well as their use may raise privacy problems for users who do not want to 
disclose to omer parties their association with a given authorization. In the case of 
authorizations as rights to access content, users may not want to be associated with certain 
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2 24.12.2003 
content. Privacy problems exist for a number of reasons. First, a public key (or its hash) is a 
globally unique identifier of the user. Moreover, it is easy to bind a public key to its owner 
smee the key is public and it is used in any transaction to authenticate the user. Second, the' 
availability discussed above implies that there is a direct and easily accessible link (the 
authorization certificate available everywhere in the network) between users and an 
authorization. Third, given a certain public key, i.e. a certain person, it is very easy for an 
observer to find all the authorization certificates of that person by simply doing a search in 
the network on that public key. Fourth and finally, even if certificates are carried and kept 
privately by users, the certificate issuer and the certificate verifier will always know that 
association between the user and the authorization, since they have (and need) access to the 
certificates. 

A solution is required that ensures and preserves privacy for users with respect 
to their certificates, while allowing easy access any time and anywhere to those certificates 
by a verifier. 

In patent apphcation EPOS 100737.0 (attorney docket PHNL030293), amethod 
is described aiming to preserve privacy for at least one user of obtained authorizations that 
can be used in an access and authorization system, while at the same time allowing the proper 
and secure check of the users entitlement to said authorization. It proposes to hide the link 
between user identities and content rights by using concealing date to conceal the user 
identity (the public key) in the user identifying information, while still allowing any device to 
check the certificates. This solution still suffers from privacy problems. When a user 
accesses content, his identity is revealed, and all the user's actions of accessing content can be 
Imked to his identity. In the process of a user accessing content, however, the device always 
learns the public key of the user, revealing his identity. Even worse, it enables that all the 
user's actions of accessing content can be linked to his identity, so, with a co-operation of 
certificates verifiers, the user can be tracked. Also, there is no privacy towards the certificate 
issuer. 

There is therefore a further need to provide privacy towards third parties such 
as the certificate verifier and also the certificate issuer. 



It is an object of the present invention to provide a method for issuing and/or 
verifying a certificate for a user, preserving privacy for that user, which prevents the 
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certificate issuer and certificate verifier from learning the user identity (public key) of that 
user, in a way that the user's entitlement to the certificate can still be verified 

This object is acbievedby a method of preserving privacy for a user while 
enabling the user controlled access to data, the user being represented by a user device and 
identified by a user identity, the method using at least one certificate that associates data 
access rights with the user identity, wherein the certificate conceals the user identity, wherein 
the certificate comprises publicly available solution information P, a concealed secret S' is 
publicly available, the method further comprises at least one of: 

a certificate verification process between the user device and a verifier device, 
a certificate issuing process between the user device and an issuing device, and 
a certificate re-issuing process between the user device and the issuing device, 
wherein the certificate verification process comprises the steps of: 

the user device obtaining the concealed secret S' corresponding to the 

certificate, 

the user device retrieving the secret S from the concealed secret S', 
the verifier device obtaining the solution information P from the certificate, 
the user device proving to the verifier device that it knows the secret S without 
the verifier device learning the secret S or the user identity, 
wherein the certificate issuing process comprises the steps of: 
20 - generating a secret Sand a solution information P, 

concealing the secret S into a concealed secret S', 
the issuing device issuing a certificate comprising at least the solution 

information P, 

wherein the certificate re-issuing process comprises the steps of: 

the user device obtaining the concealed secret S' corresponding to the 



certificate, 



the user device retrieving the secret S from the concealed secret S', 
the issuing device obtaining the solution information P from the certificate, 
the user device proving to the issuing device that it knows the secret S without 
30 the issuing verifier device learning the secret S or foe user identity, 

generating a new secret S2 and new solution information P2, 
concealing the secret S2 into a concealed secret S2 ', 
the issuing device issuing a new certificate comprising at least the new 
solution information P2. 
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4 24.12.2003 
The user identity and public key are not available in clear format in the 
certificate, and are also not needed for the verifier to verify the authorization. The 
authorization is verified by the user proving to the verifier device that the user knows the 
secret contained in the authorization. 
5 Because the secret S itself is not revealed, the verifier can not impersonate 

himself as the user related to the authorization, and privacy is preserved. 

An advantageous implementation of the method according to the invention is 
described in claim 2. The concealed secret S' is now also conveniently stored in the 
certificate. 

10 An advantageous implementation of the method according to the invention is 

described in claim 3 . As only the user has access to the private key, only the user can retrieve 
the secret S. 

A further advantageous implementation of the method according to the 
invention is described in claim 4. 

An advantageous implementation of the method according to the invention is 
described in claim 5. By the use of random information, the secret 5 can be better concealed. 

A further advantageous implementation of the method according to the 
invention is described in claim 6. By using a zero knowledge protocol between the verifier 
and the user, the knowledge of the secret S is proven but the secret itself is not revealed. 

A further advantageous implementation of the method according to the 
invention is described in claim 7. By establishing a symmetric session key * the issuing 
process is protected. 

A further advantageous implementation of the method according to the 
invention is described in claim 8. In order that nobody else knows the secret, the secret is 
preferably generated by the user device itself in the issuing process. 

The invention can be applied advantageously for an authorization certificate 
as defined in claim 9, or can be applied advantageously for a domain certificate, as defined'in 
claim 10. 

m patent application EP02079390.7 (attorney docket PHNL021063), a method 
is proposed which describes an architecture for an authorized domain based on persons 
Access to content is granted to any of the persons in the domain based on a few steps. Person 
A (who bought the content) may access content 1 on a device by means of authentication, 
e.g. with As user device, and the usage right certificate, a certificate which links A to content 
rights 1 . Persons B, C, and D (who belong to the same domain as A) may access content 1 on 
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a device by means of authentication based on the usage right certificate which links A to 
content rights 1, and the domain certificate, a certificate which groups A, B, C and D 
together. When a person performs an action that requires him to show mat he is a participant 
in a domain, his user identity (public key) is revealed as it is part of foe domain certificate. 

A domain certificate according to foe invention contains one or more 
concealed secrete of which foe secret can only be retrieved (and knowledge thereof proven) 
by foe domain members. This enables foe domain members to anonymously prove their 

membership in foe domain. 

An advantageous implementation of foe method according to foe invention is 
described in claim 1 1. As each domain member has access to foe secret domain key, foe 
domain members made retrieve foe secret S from foe domain certificate. 

A further advantageous implementation of foe method according to foe 
invention is described in claim 12. The usage right certificate may comprise a concealed 
secret (such as D in foe second embodiment described below) that links foe usage right 
certificate to a domain in order to allow foe (other) domain users (foe co-users) to prove foeir 
entitlement to foe usage right certificate. 

A further advantageous implementation of foe method according to foe 
invention is described in claim 13. Different access levels can be from last by having a rule 
with right specifications, stating foe different permissions a user is entitled to when proving 
either secret. 

It is a further object of foe present invention to provide a user device that can 
request a certificate or prove entitlement to a certificate according to foe invention, 
preserving foe privacy of its user identity. This object is achieved by a user device being 
arranged for issuing a certificate according to claim 1, comprising: 

receiving means for receiving process information, 

computing means, comprising processing, encryption/decryption and storing 
means, for engaging in at least one of foe certificate verification process, foe certificate 
issuing process, and certificate re-issuing process, 

transmitting means for transmitting process information. 

It is a further object of foe present invention to provide a verifier device for 
verifying a user's entitlement to a certificate, while preserving foe privacy of foe user. This 
object is achieved by a verifier device being arranged for verifying a certificate according to 

claim 1, comprising: 

receiving means for receiving process information, 
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computing means, comprising processing, encryption/decryption and storing 
means, for engaging in the certificate verification process, 

transmitting means for transmitting process information. 

It is a further object of me present invention to provide an issuing device for 
issuing a certificate according to the invention, preserving the privacy of the user. This object 
is achieved by an issuing device being arranged for issuing a certificate according to claim 1 
comprising: " ' 

receiving means for receiving process information, 

computing means, comprising processing, encryption/decryption and storing 
means, for engaging in at least one of toe certificate issuing process and certificate re-issuine 
process, 

transmitting means for transmitting process information. 
It is a further object of the present invention to provide a signal for preserving 
privacy while enabling the user controlled access to data. This object is achieved by a signal 
carrying at least part of a certificate as used in the method according to claim 1. 

It is a further object of the present invention to provide a computer program 
product for preserving privacy for a user while enabling the user controlled access to data 
This object is achieved by a computer program product carrying computer executable 
instructions comprising a computer readable medium, having thereon computer program 
code means, to make a computer execute, when said computer program code means is loaded 
m the computer, implementing at least one protocol side of at least one of: 
the certificate issuing protocol, 
the certificate re-issuing protocol, and 
the certificate verification protocol. 

It should be understood, that although the invention is described using a 
certificate, that the invention is not limited to a certificate per se. Tne same publicly available 
mformatxon can be available in whole or in parts and can be separately certified. 



30 These and other aspects of the invention will be further described by way of 

example and with reference to the schematic drawings, in which: 
Fig. 1 illustrates a verification protocol, 
Fig. 2 illustrates an issuing protocol, 
Fig. 3 illustrates a re-issuing protocol, 
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Fig. 4 illustrates a verification protocol for a domain co-user, 

Fig. 5 illustrates an issuing protocol for a domain user, 

Fig. 6 illuslrates a issuing protocol for a domain certificate, and 

Fig. 7 illuslrates a system with a verifier device, a user device, and issuing 

device. 



In a first embodiment according to the invention, the authorization system 
comprises different devices, as illustrated in Fig. 7. Shown is a user device 721 , which can 
for examplebe a smart card or a USB dongle. Further shown is an issuing device 711 for 
issuing certificates, a verifier device 701 for verifying a certificate which gives entitlement to 
content, and a content device (which is in this illustration combined with the verifier device, 
but which could also be a different device) for providing content These devices can be 
interconnected through a network 740, but can also be interconnected directly as illustrated 
with communication channels 741 and 742. Each of the devices 701,71 1,721 has receivings 
means 706,716,726 for receiving information from anetwork or from other devices, for 
example during the protocols described in the sequel. Each of these devices further has 
transmitting means 707,717,727 for transmitting during these protocols, and has a processing 
nnit 702,712,722 for processing information during protocol handling, this processing unit 
comprising a processor 703,713,723, a memory 704,714,724 that can also store key 
information, and encryption/decryption functionality illustrated in block 705,715,725. 

Verifier devices and user devices are assumed to be compliant. This means 
that these devices comply with a given standard and adhere to certain operation rules. For a 
device this means, for instance, mat it does not output content illegally on a digital interface. 
For a user device, this means that it keeps its secrets secret, and that it answers to questions 
and requests posed to it in the expected way. 

The authorization certificate is a person's right to access a piece of content, 
and it is represented by means of the content right identifier, crjd. In its simple format it can 
be defined as { crjd , PK Wcp, where PK is the public key of the person being granted the 
right to access content crjd, and signCP is the signature of for example the issuing device on 
the certificate. When a user wants to access content with this certificate, he must show it to a 
verifier device which is able to give him directly or indirectly access to the content. User 
authentication must be performed, which can be accomplished by means of a protocol 
between the verifier device and the user device (e.g., a personal smart card), which is 
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possessed by every user and contains a unique private/public key pair for each user. The 
public key of a user is therefore the identifier for that user in the system. 

In this first embodiment according to the invention, a new format for the 
authorization certificates is used in which the user's public key is not in the clear. Moreover 

5 in order to prevent toe verifier device fi^m learnmg me pubuc key of me user device, toe new 
format is such that certificates verification is performed by means of a zero-knowledge 
protocol between toe verifier device and toe user device. This means that after toe 
verification protocol, toe verifier device is convinced that toe user device knows some value 
(toat only toat user device could know), but nothing is revealed to toe verifier device about 

) toat value. 

The Fiat-Shamir identification protocol (as described in Schneier, B., Applied 
Cryptography: protocols, algorithms and source code in C, 2 nd edition, John Wiley '& Sons, 
1996) can be used to prove to a verifier device the knowledge of a secret value S e Z„\ 
whose square value, P = S 2 , is available as solution information to toe verifier device^This 
problem is based on the fact toat computing square roots in the multiplicative group is a 
hard problem In applications were communication cost is an issue, for example if the user 
device is implemented using a smart card, toe GuiUou-Quisquater identification protocol 
(also described in toe same book by Schneier) is more suited, since exchanges between the 
user device and toe verifier device can be kept to a minimum. 

The format for toe authorization certificate according to the invention is for 
example as follows: 

usage right certificate = { arid , P , PK[S J } signCP> 
where S is a secret value chosen in Z n \ the value P=S 2 , and PKfS J is the encryption with toe 
public key PK of toe certificate's owner (referred to as user U) of toe value S. This value is a 
different randomly chosen value in zS for each usage right certificate of user *7(i.e., for each 
content crjd), so the value P=S> is also unique per certificate. The user identity PK, 
however, which is the same for all certificates of a given user, is not in toe clear. Because 
only toe user has access to toe private key corresponding to toe public key used for toe user 
identity, only toe user can retrieve S from toe authorization certificate. The certificate is 
preferably signed by a trusted party such as toe issuing device (which can be toe content 
provider). 

Because toe link between toe authorization and toe user identity is not in the 
clear in toe certificate anymore, different authorization certificates of a single user cannot be 
linked. Although toe verifier can be convinced that toe user knows toe secret S, he does not 
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learn that value and also not the identity of the user public key PK 9 preserving the privacy of 
the user. 

Note that it is not necessary to keep the iS- values in storage in the user device. 
The step of user authentication happens implicitly when the user device retrieves the value S, 
for only a user who knows the private key SK, corresponding to the user public key PK, is 
able to decrypt PK[ S] to obtain the value S. 

Devices must be capable of checking the usage right certificates to give access 
to content only to users who are entitled to it This can be done by means of a verification 
protocol as illustrated in Fig. 1 . The protocol between a user device 110 that contains the 
private key of the user, and a verifier device 111 verifying the authorization certificate, 
illustrated along the timeline 120, consists of the following steps: 

step 131: the user device transmits to the verifier device the content identifier 
cr_id and optionally locator information in order to ask for content crjd. The optional 
locator can be sent to help the verifier device find the correct usage right certificate, 

the verifier device retrieves the correct usage right certificate, 

step 1 32: the verifier device sends the value PKfSJ to the user device, 
the user device retrieves the value S using its private key (by which the authentication 
happens implicitly), and 

step 133: the user device engages in the zero-knowledge protocol with the 
verifier device in order to prove that it the user device knows S. 

During the zero-knowledge protocol, there are a number of rounds, and in 
each round, the verified device confidence increases. If the verifier device is sufficiently 
convinced that the user device knows the square root of P, it acts accordingly. If the verifier 
device acts as content device, it can give the user U access to the content In another 
variation, the verifier device can communicate the results to a different device operating as 
content device. 

Fig. 2 illustrates an issuing protocol along a timeline 220 between a user 
device 210 and an issuing device 21 1, that provides privacy for users towards the certificate 
issuing device as well. This mechanism allows users to anonymously acquire the certificates, 
yet the issuing device can ensure that the association between user and authorization, to be 
signed by him, will be legitimately used. In case the authorization is obtained through 
buying, a mechanism must be provided for the anonymous buying of certificates. Usage right 
certificates can be issued anonymously based on for example the pre-payment scheme 
described in EP03100737.0 (attorney docket PHNL030293), in which the user buys 
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(anonymously) from the issuer a token with a secret security identifier (SSI) on it This token 
can only once he used and the identifier SSI must therefore he invalidated after use. When the 
user device wants to obtain the rights for some content, he contacts the issuing device 
anonymously with a request for anonymous buying. The protocol consists of the following 
5 steps: 

step 231: preferably, a symmetric session key Kis established between the 
user device and the issuing device, in order to encrypt all information exchanged between 
them to ensure that the communicating parties are the same throughout the buying 
transaction. The key is for example established by transmission from the user device to the 
10 1S sumg device, where the key is protected during transmission by encryption with the user 
device's public key, 

step 232: the user device sends a request for the content right, e.g. the value of 
crjd, and the encrypted lvalue, bothpreferably encrypted with the session key K, 
the issuing device verifies the validity of SSI and invalidates the token 

15 identifier, 

the value S e Z,' is preferably generated by the user device, in oider that only 
the user device may know S. The user device can then calculate the values P=S> and PK[S], 

step 233: the user device transmits the values P and , preferably 

concatenated with the crjdio link this communication to the previous communications and 
preferably encrypted with the key iSTfor secure transmission, and 

the issuing device creates and signs the usage right certificate as defined 
above, and the issuing device can subsequently make the usage right certificate available in 
the network. 
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It is a further advantage of this embodiment that anyone knowing the public 
key of a certain user can buy a usage right certificate for that certain user, for example as a 
present 

Re-issuing of certificates can be useful in certain cases, such as when a 
certificate has a limited lifetime, or when the appropriate value of crjdhas to be changed, m 
that case the certificate should be re-issued. Fig. 3 illustrates such a re-issuing protocol 320 
between a user device 310 and an issuing device 31 1. An anonymous re-issuing process is 
normally started by the user that owns the usage right certificate, who contacts the issuing 
device anonymously with a request for the re-issuing: 

step 331: a session key is established in step 331, for example by the user 
device sending the encrypted session key to the issuing device, 



PHNL03 1 509EPP 

n 24.12.2003 
step 332: the user device then sends in step 332 his old usage right certificate 
or the reference crjd to the old usage right certificate, 

the issuing device has received or can now retrieve the P and PKfSJ values for 

the old usage right certificate, 

step 333: the user device proves to the issuing device that he is the legitimate 
owner of that usage right certificate by proving knowledge of the value S in the certificate 
(just as with the device when the user requests content), 

the user device generates new values P and PKfSJ for the new usage right 



10 



certificate, 
and 



step 334: the issuing device receives the newly generated values P and PKfSJ, 



the issuing device creates and signs the re-issued usage right certificate, which 

can then be made available in the network. 

Each time a user accesses content, he shows his usage right certificate to the 
15 verifier device. This may allow co-operating verifier devices to track users, since transactions 
involving the same usage right certificate (i.e., the same content) are all linkable via its values 
crjd, P and PKfSJ. In case the public key is revealed during a single transaction (either by 
accident or by an attacker), all the other transactions involving the same usage right 
certificate can be linked to that user. However, as long as the user's identity is not revealed, 
20 the transactions can be linked together but not linked to the user. 

The linkability can be reduced by re-issuing with fresh values of P and PKfSJ. 
For full privacy, this should be done after each single use. Such a re-issuing may be 
prohibitive in cases where it creates too much of a burden on the issuing device or user 
device. Besides, a user device might not even be able to contact the issuing device prior to a 
25 content access request Therefore, privacy threats must be weighed against the burden of the 
frequent re-issuing, especially in the case of usage right certificates where linkability only 
happens in requests for the same content A cheaper alternative is to perform occasional re- 
issuing, or re-issue only on request of the user. 

The re-issuing of a given usage right certificate, is especially useful in case the 
30 user's public key is revealed, for example during a verification protocol. Re-issuing will men 
prevent that the user is tracked mjuture transactions of access to the corresponding content 

In a first variation of the first embodiment the invention increases the security 
of the usage right certificate, thereby increasing the secrecy of the value S. This value S must 
be kept secret and should remain available only to the user. However, since the two values 
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PS* and PKfSJ are in the clear in the certificate, an attack could be possible in which the 
value S is obtained from the knowledge of those two values. The following format for the 
usage right certificate provides additional security: 

usage right certificate = { crjd , P , PK[S//RAN ] } sisnCP , 
where RAN is another randomly and secretly chosen number in Z^* for each value S 
(therefore for each crjd) and the symbol //indicates concatenation of strings. With the 
introduction of the value RAN, the values P and PK[S//RAN] in the certificate are not 
uniquely related anymore, so an attack to discover S is much more difficult. 

In a second variation of the first embodiment, an easy method is provided to 
search for a user's usage right certificate. Since the user's public key is not in the clear in the 
certificate anymore, finding such a certificate anywhere in the network can be greatly 
facilitated by an additional field, an index /, in the certificate. The new format is as follows: 

usage right certificate = { crjd , P , PRfS J , I } signCJP> 
where the index /= SKjfcrJd], i.e., the encryption of crjd with a secret symmetric key 
SKl - Tbis kev is stored a *■ ™« device and is only used for thatpurpose. Here, the 
encryption scheme used is assumed to be resistant against known plain-text attacks, to ensure 
that an attacker cannot easily find the key SK T from crjd and SK lf crJd /. In case such 
attacks are possible, two alternative improved forms for /are: 

the index may be calculated as the square I=(SKt[crJd] )\ whose square 
root is hard to compute (the values crjd and SKj are such that SKJ crjd ] « Z.\ which can 
be accomplished by choosing crjd e Zn* and SKj e Zn\ or 

the index may be calculated as I = SK/ [ SK, [ crjd ] ], where the key SK r ' 
can be derived from the stored secret key SK, using a hash function ffasSK,' = H(SKj). 

In both cases, only the user can calculate /and an attacker has no longer 
available to him both the plain text crjd and the corresponding cipher text SKJcrJd]. 

A second embodiment according to the invention makes use of a so-called 
authorized domain architecture. Patent application EP02079390.7 (attorney docket 
PHNL021063) describes a usage right certificate in the context of a person-based authorized 
domain architecture, which contains a reference in the certificate to a domain. 

According to the present invention, the domain certificate is defined in a 
manner to conceal the public keys of the members. To achieve this, the new format for the 
domain certificate is: 

domain certificate = {djd, P ,PK[S '] ,PK?S J ,PK»[S ] . ... }signDC , (4) 
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where djd is the domain identifier, P is calculated as P = (SK D [ S])\ SK D is a secret 
symmetric domain key shared by domain members only, and stored in their user devices, S 
is a value which is generated when the domain certificate is issued, and PKfSJ, PK'fS] , 
PK"fSJ, ... are the encryptions of S with the respective public keys of all domain members. 
The domain certificate is preferably signed by the domain authority DC. 

With the format above, users who are a domain member can prove to a verifier 
device that they belong to domain djd by means of a zero-knowledge protocol where they 
prove knowledge of the secret value SK D fSJ=J?. This value can be calculated only by 
domain members, who can obtain S (by decrypting one of toe terms PKfSJ, PK'fS J, .. .) 
and encrypt it with SK D . The value S is a secret value which is generated and used by the 
domain certificate authority upon the issuing of the domain certificate. Its knowledge would 
allow any person to check if a certain public key belongs to domain djd. 

The format for the usage right certificate, that links to the domain without the 
domain identifier having in the clear, is for example defined as follows: 
15 usage right certificate = { crjd , P , PKfSJ , D }stgnCP, 

where the domain tennis calculated as D=(SK D fS x crjdjf and the symbol x indicates 
multiplication of numbers in (the value crjd is also chosen in Zn*). 

The value D is used to allow any other domain user (a so-called co-user) XT to 
prove to a verifier device that he also is entitled to access content crjd. He can do so by 
20 means of a zero-knowledge protocol in which he proves knowledge of the secret value 

SK D fS x crjdj= J5 . 

In the protocol the domain certificate is needed in order for U' to obtain the 

value S , since it is not kept in storage in the domain users' user devices. Also, the 
multiplication of S by crjd makes the value D different for different usage right 
25 certificates. As with SK D fS J, this secret value can be calculated only by domain members. 

Devices must be capable of checking the certificates in order to give access 
only to users who are entitled to the content. These are user C/(whose public key is PK) and 
any other co-user V (whose public key is PK') in the domain. The verification protocol for 
the checking by a verifier device of the usage right certificate of user U is equal to the 
30 protocol as used in Ihe first embodiment For co-user IT, the verification protocol is shown 
schematicaUy in Fig. 4. User device 410 is now related to co-user IT . The verification 
protocol with the verifier device 41 1 consists of: 
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step 431: the user device requests access to content crjdby sending crjd and 
Ms domain identifier djd to the verifier device. A locator, such as the index SK D [crjd] is 
optionally also sent to help the verifier device find the correct usage right certificate. 
Preferably, SK D equals SK r for efficiency reasons, 

the verifier device retrieves the domain certificate and the correct usage right 



certificate 
device, 



step 432: the verifier device sends the values PK[S ],PK'[S ], ... tothe user 



30 



- ^ the user device can obtain the value S by using its secret key SK' to decrypt 

PK'fS]. It then calculates the values SK D [S ] and SK D [S x crjd], 

step 433: the user device engages in a zero-knowledge protocol with the 
verifier device to prove its knowledge of SK D [S]= yfp , 

step 434: the user device engages in a zero-knowledge protocol with the 
verifier device to prove its knowledge of SK D fS x crjd]= 4d , and 

if the verifier device is sufficiently convinced that the user device knows both 
the square root of P (from the domain certificate) and the square root of D (from the usage 
right cernficate), it can then give the user U> access to the content, by transmitting the content 
itself, if the verifier device acts as content provider, or by for example informing the content 
provider about the protocol results. 

All compliant user devices whose public keys were used to encrypt S in the 
domain certificate and which contain the secret domain key SK D are capable of obtaining S 
and calculating SK D [ S] and SK D [S x crjd]. The proof of knowledge of 4¥ proves that 
the user ^'belongs to the domain djd, and the proof of knowledge of VI> links the usage 
right certificate for content crjd to that domain. 

Fig. 5 illustrates the implementation of an issuing protocol 520 that also 
preserves privacy towards the certificate issuing device for users in a domain while issuing a 
usage right certificate for use by each domain member. Usage right certificates can be issued 
anonymously based on for example the pre-payment scheme described in EP03 100737 0 
(attorney docket PHNL030293), in which the user device 5 1 0 buys (anonymously) from the 
issuing device 511a token with a secret security identifier (SSI) on it The issuing protocol 
consists of: 
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the user device wants to obtain the rights for some content, and contacts the 
issuing device anonymously with a request for anonymous buying, 

step 53 1 : a symmetric session key K is preferably established between the user 
device and the issuing device, in order to encrypt all information exchanged between them to 
5 ensure that the communicating parties are the same throughout the buying transaction, 

step 532: the user device sends in step 532 a request for the content rights, e.g. 
the value of crjd 9 and the SSI value, both preferably encrypted with the session key K, 

step 533: the user device send the value djd to the issuing device, preferably 
encrypted with the session key K, 
10 the issuing device verifies the validity of SSI and invalidates that identifier, 

based on the domain identifier d_id 9 the issuing device then fetches the 
corresponding domain certificate from, e.g., a public directory, 

step 534: the issuing device (optionally) sends the values PK[S ] 9 PK'fS ] 9 . . ., 

from the domain certificate to the user device, 
15 the value S e Zn* is preferably generated by the user's user device. The values 

P=*S* and PK[S] are calculated by the user's user device after it generates the value S e Z n *. 

To calculate D=( SK D [ S x crjd] ) 2 , the user device needs the value S , which can be 

obtained from the optionally received values PK[ S ] 9 PK'fS ] 9 . . ., but which could also be 

received for example from a different source, 
20 - step 535 : the user device sends the values P, PKfSJ and D to the issuing 

device. These values are preferably concatenated with crjd and preferably encrypted with 

the session key K 9 and 

the issuing device creates and signs the usage right certificate, and makes it 

available in the network 

25 In case the user does not belong to any domain, there is no domain certificate 

from which the value S can be obtained and, in this case, the issuing device or user device 
can simply set D to a random value generated by itself. 

It is a further advantage of this embodiment that anyone within the domain 
knowing the public key of a certain user can buy a usage right certificate for that user. This 
30 allows to buy content, for example as a present, for a different user. 

The protocol for the issuing of domain certificates is shown schematically in 
Fig. 6. domain certificates are issued to a user device 610 in or representing a domain by a 
domain authority 6 1 1 which knows or learns the users 1 identities and public keys PK 9 PK\ . . 
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which are to be grouped together in the certificate. This authority also generates the secret 
value S and a domain identifier djd. The domain members, on the other hand, establish 
secretly a symmetric domain key SK D (if one does not exist already), which is to be stored in 
their user devices. The values S and SKd are such that SK D [S 7e Zn* 9 which can be 
5 accomplished by choosing S & Zn* and SKd e Z^. 

The domain certificate issuing protocol 620 is established between the 
authority and the user device of a domain user, with all communication done via a Secure 
Authenticated Channel (SAC). 

step 63 1 : the domain authority successfully authenticates the user device, 
10 - the domain authority generates a random value S and a domain identifier 

djd, 

step 632: the domain authority sends user device S and d_Jd 9 

the user device then calculates P = (SK D [ S]) 2 , 

step 633: the user device sends P to the domain authority, and 
15 - the values PK[ S /, PK'[ S/, ... can be calculated by the authority itself and, 

together with P and djd, they can be inserted in the domain certificate to be signed. 

From the issuing of a domain certificate, the authority knows the secret value 
S and the association between the domain identifier djd (and also P ) and the public keys 
of the users in the domain. It does not learn, however, the value SK D [S ] which can only be 
20 calculated by domain members. This is the reason why P is not simply set as P = S 2 9 in 

order to make sure the domain certificate can not impersonate himself as a domain member. 

Whether co-user XT accesses the same or different content in two transactions, 
even though he is always linked to the same domain d_Jd, he has always anonymity within 
the domain. The fact that the public keys of domain members are not in the clear in the 
25 domain certificate also reinforces that anonymity. This fact allows user *7to also prevent the 
linkability of his transactions and gain anonymity within the domain, by accessing his content 
via his domain membership. Anonymity within the domain is especially advantageous in case 
the domain is not too small. 

Re-issuing of certificates as described for the first embodiment also avoids 
30 linkability of users 1 transactions for the second embodiment. 

Note that the user U still can prove that it knows S which gives the user an 
advantage over a co-user IT in the domain who cannot do so. This difference can 
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advantageously be exploited in situations where the user should have more privileges than 
the other domain users. For example, the other users could have time limits or frequency 
limits on content access. 

In a different environment, where the certificates would be used as access 
5 control to e.g. medical data, one could imagine that the user itself would have total access to 
his own data, while the other users have limited access to his medical data. 

In yet a different environment, the user could have read and write access while 
other users only have read access to data. 

This could be formalized by having a rule with rights specifications, stating 
10 the different permissions a user has when (1) proving its domain membership or (2) when 
(also) able to prove knowledge of S. 

In a first variation of the second embodiment, when the user U does not need 
special privileges compared to the other users U% the usage right certificate can be simplified 
to: 

15 usage right certificate = { crjd P}signcp 

because any user in the domain (and only users in the domain) can prove to know D. It is 
therefore sufficient to prove knowledge of D to prove entitlement to access crjd 9 and there is 
no reason to include P, PK[S] in the usage right certificate anymore. 

In a second variation of the second embodiment, the usage right certificate 
20 could be simplified by replacing D with djd. The usage right certificate then looks like 
usage right certificate = { crjd , djd} sign cp 

or 

usage right certificate = { crjd , P , PK[ S J , djd jstgncp 

Only the users in the domain can prove that they are actually a domain user; 
25 therefore they are entitled to access the content crjd , which is publicly visibly tied to djd, 
even without proving any other secret than the secret in the domain certificate. Thus in the 
verification protocol step 434 can be skipped, reducing protocol cost. 

This usage right certificate can be issued without knowing S . This may be an 
advantage as the usage right certificate can be bought by a user device for a different domain. 
30 It should be noted that the above-mentioned embodiments illustrate rather than 

limit the invention, and that those skilled in the art will be able to design many alternative 
embodiments without departing from the scope of the appended claims. 

In the claims, any reference signs placed between parentheses shall not be 
construed as limiting the claim. The word "comprising" does not exclude the presence of 
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elements or steps other than those listed in a claim. The word "a" or "an" preceding an 
element does not exclude the presence of a plurality of such elements. The invention can be 
implemented by means of hardware comprising several distinct elements, and by means of a 
suitably programmed computer. A single processor or other (programmable) unit may also 
fulfill the Amotions of several means recited in the claims. 

In the device claim enumerating several means, several of these means can be 
embodied by one and the same item of hardware. The mere fact that certain measures are 
recited in mutually different dependent claims does not indicate that a combination of these 
measures cannot be used to advantage. 
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CLAIMS: 



1 . A method of preserving privacy for a user while enabling the user controlled 

access to data, 

the user being represented by a user device (1 10,721) and identified by a user 

identity, 

5 the method using at least one certificate that associates data access rights with 

the user identity, 

wherein the certificate conceals the user identity, 
the certificate comprises publicly available solution information P, and 
a concealed secret S 9 is publicly available, 
10 the method further comprises at least one of 

a certificate verification process (120,420) between the user device and a 
verifier device (1 1 1,701), 

a certificate issuing process (220,520,620) between the user device and an 
issuing device (21 1,711), and 
15 a certificate re-issuing process (320) between the user device and the issuing 

device, 

wherein the certificate verification process comprises the steps of 

the user device obtaining the concealed secret S* corresponding to the 

certificate, 

20 - the user device retrieving the secret S from the concealed secret S' , 

the verifier device obtaining the solution information P from the certificate, 
the user device proving to the verifier device that it knows the secret S without 
the verifier device learning the secret S or the user identity, 
wherein the certificate issuing process comprises the steps of: 
25 - generating a secret S and a solution information P, 

concealing the secret S into a concealed secret 5", 
the issuing device issuing a certificate comprising at least the solution 

information P, 

wherein the certificate re-issuing process comprises the steps of 
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the user device obtaining the concealed secret S 9 corresponding to the 

certificate, 

the user device retrieving the secret S from the concealed secret S\ 
the issuing device obtaining the solution information P from the certificate, 
5 the user device proving to the issuing device that it knows the secret S without 

the issuing verifier device learning the secret S or the user identity, 

generating a new secret S2 and new solution information P2, 
concealing the secret S2 into a concealed secret S2 \ 
the issuing device issuing a new certificate comprising at least the new 
1 0 solution information P2. 

2. The method according to claim 1, wherein the certificate comprises publicly 

available concealed secret S '. 

15 3. The method according to claim 2, wherein the secret S is encrypted with the 

user's public key to generate the concealed secret S\ 

4. The method according to claim 1, wherein the solution information P and the 
secret S are members of Zn*, and the solution information P is the square of S. 

20 

5. The method according to claim 1 , wherein the concealed secret S' comprises 
random information RAN. 

6. The method according to claim 1, wherein the verifier device verifies that the 
25 user device has knowledge of the secret S using a zero-knowledge protocol. 

7. The method according to claim 1, wherein the communication during the 
issuing process is protected using symmetric key encryption, 

30 8. The method according to claim 1, wherein in the issuing process the secret S 

and the solution information P is generated by the user device. 



9. 



The method of claim 1, wherein the certificate is an authorization certificate. 
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10. The method of claim 1, wherein the certificate is a domain certificate. 

1 1 . The method according to claim 1 0, wherein the concealed secret S' in the 
domain certificate comprises the secret S, encrypted with the secret domain key. 

5 

12. The method according to claim 9, wherein the concealed secret S f comprises 
the secret S, multiplied with cr _id. 

13. The method according to claim 1 , wherein the certificate comprises two 
10 secrets, of which the knowledge prove by a user device gives different access levels. 

14. User device (1 10,721) being arranged for issuing a certificate according to 
claim 1, comprising: 

receiving means (727) for receiving process information, 
15 - computing means (722), comprising processing (723), encryption/decryption 

(725) and storing means (724), for engaging in at least one of the certificate verification 
process, the certificate issuing process, and certificate re-issuing process, and 

transmitting means (726) for transmitting process information. 

20 15. Verifier device (111,701) being arranged for verifying a certificate according 

to claim 1, comprising: 

receiving means (707) for receiving process information, 
computing means (702), comprising processing (703), encryption/decryption 
(705) and storing means (704), for engaging in the certificate verification process, and 
25 - transmitting means (706) for transmitting process information. 

16. Issuing device (21 1,71 1) being arranged for issuing a certificate according to 

claim 1, comprising: 

receiving means (717) for receiving process information, 
30 - computing means (712), comprising processing (713), encryption/decryption 

(715) and storing means (714), for engaging in at least one of the certificate issuing process 
and certificate re-issuing process, and 

transmitting means (7 1 6) for transmitting process information. 
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1 7. Signal carrying at least part of a certificate as used in the method according to 
claim 1. 

18. A computer program product (732) carrying computer executable instructions 
5 comprising a computer readable medium, having thereon computer program code means, to 

make a computer execute, when said computer program code means is loaded in the 
computer, implementing at least one protocol side of at least one of: 
the certificate issuing protocol, 
the certificate re-issuing protocol, and 
10 - the certificate verification protocol. 
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ABSTRACT: 



The invention proposes a method to provide privacy for users or a user from a 
group of users with respect to authorizations they are granted, where such authorizations are 
expressed using digital authorization certificates, and with respect to domain certificates in 
case of groups of users. The idea is to conceal the user identity in the certificates, while the 
5 certificate itself remains in the clear. In this way, certificates can be widely and openly 

available, e.g. in a public network, without a random observer being able to link a user to an 
authorization or to identify a user within a domain. Privacy is also provided towards the 
certificate verifier by means of zero-knowledge protocols, which are carried out between the 
user and the verifier in order for the verifier to check a user's entitlement to a certificate. 
10 Privacy is further provided towards the certificate issuer as well, by means of a mechanism 
that allows the anonymous (buying or) issuing of certificates from the issuer. 
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